Derrama: REST API Authentication Integration

Introduction

This document explains how the Derrama store delegates user sign-in to a client-owned REST API while we generate the JSON Web Token (JWT) that grants access to Publica.la. The flow combines a Livewire form in an embeddable iframe and backend services that validate credentials against the external API, create or link the user account, and return a secure session.

Integration Route

Endpoint: /1125899921000028/embeddable-login-ui/

Integration Description

The client Derrama has a virtual store at {store_final_domain} and the authentication integration is performed through communication with an external server (REST API) owned by the client. This server is responsible for authenticating users.

To efficiently manage authentication, a REST API-based integration is implemented.

Authentication Process

1. When a user wants to authenticate, the system displays a Livewire form where they can enter their identification data.
2. Once entered, the data is validated on the remote REST API server, which indicates whether the user has access permissions.
   1. Users can provide an alternative password, which they obtain from the web platform. This password differs from the one validated by the API and is only validated on Publica.la.
3. After authentication succeeds, the system returns the information required to grant the user access to Publica.la.

Full Authentication Flow

1. The user (guest) enters the store.
2. The user selects "Log in".
3. Integration loading:
   1. The login form appears.
   2. The user authenticates in the form and indicates whether an alternative password was provided or the system should validate credentials through the REST API server.
      1. If the user entered the alternative password, proceed to step 3.6.
   3. The integration processes the verification and validation data required to authenticate the user in the store.
   4. A JWT is generated with the user's email and external_id to start a session in Publica.la:
      • If the user does not exist, the system creates a new account.
      • If the account exists, the system links it through email and external_id.
   5. The information is sent via postMessage to the host that contains the iframe:
      • In the App, the Token is stored directly.
      • In Web, the system stores an Auth Token (documentation).
4. The user remains logged in on the platform.
5. If the user decides to log out:
   • The session closes in the store.
   • The authentication flow can restart at any time.

Representation of the Authentication Flow

---